AWSのCLI作業はどこで行う？安全に管理するパターンとメリデメ集

王道4パターン。

AWSアクセスキーセキュリティ意識向上委員会

#AWS CLI

#AWS CloudShell

#AWS Systems Manager（SSM）

#AWS

加藤早織

2021.05.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSアクセスキーセキュリティ意識向上委員会って何？

昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、
多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。

そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。

アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、
セキュリティ対策を事前に適用した上で適切にご利用ください。

AWS CLI、どこから使っていますか？

ざっくり、以下4種類のどれかを使っている方が多数派ではないでしょうか。

ローカル端末
AWS内に構築した管理用EC2にSSHを利用して接続
AWS内に構築した管理用EC2にSSM(セッションマネージャ)を利用して接続
AWS CloudShell

一体どう違うのでしょうか。
状況によって良し悪しは異なると思いますが、今回は3つの観点から比較してみました。

アクセスキー管理
操作ログ記録
環境構築・運用

(※ 本記事ではLinuxサーバを想定しています)

最初にまとめ

独断ですが、こうなりました。

場所	IAMアクセスキー	シェル操作ログ	AWS API操作ログ	環境構築・運用
ローカル端末	△必要	△ 各自用意	○ IAMユーザまで追跡可能	○ (ただし職場ルール等による)
EC2 + SSH	○不要	△各自用意	(△-) 別途EC2ログインユーザを特定する仕組みが必要	△EC2管理
EC2 + SSM	○不要	○ S3, CloudWatchLogsへの自動出力機能あり	(△+) セッション履歴、シェル操作ログからユーザ特定	△ EC2管理
CloudShell	○不要	△ 各自用意	○ IAMユーザまで追跡可能	○ 不要

アクセスキーが不要なのは EC2 + SSH、 EC2 + SSM、CloudShell
- ローカル端末を使う場合は、アクセスキーの管理に気をつける必要あり！！
ログ記録機能が優秀なのは EC2 + SSM
環境構築・運用が不要なのはCloudShell

各接続方法の整理

ローカル端末

ローカル端末の場合、アクセスキーを使う運用が基本となります。

AWSアクセスキーを利用するベストプラクティスは以下のとおりですが、基本的には「多くの場合、期限のない長期のアクセスキー (IAM ユーザーのアクセスキーなど) は必要ありません。」と言われています。

多くの場合、期限のない長期のアクセスキー (IAM ユーザーのアクセスキーなど) は必要ありません。その代わり、IAM ロールを作成し、一時的なセキュリティ認証情報を生成できます。一時的なセキュリティ認証情報は、アクセスキー ID とシークレットアクセスキーで構成されていますが、認証情報がいつ無効になるかを示すセキュリティトークンも含んでいます。

引用: AWS アクセスキーを管理するためのベストプラクティス - AWS 全般のリファレンス

特にEC2の電源操作、IAMユーザの作成など、強い権限を持つアクセスキーをこの方式で運用するのは避けたいところです。

ベストプラクティスに寄せていくため、できるだけIAMユーザには最小限の権限を持たせ
より広い権限を持ったロールにMFAを用いてスイッチロールするなどの方法をおすすめします。

AWS内に構築した管理用EC2にSSHを利用して接続

管理用に構築したEC2インスタンスにSSHで接続し、
EC2にアタッチされたIAMロール(インスタンスプロファイル)を利用する運用です。

アクセスキーの発行は不要です。

ただし、IAM以外に、SSH用のポートを開ける必要がある/OSのユーザやSSH鍵等を管理する必要がある等の点で考慮事項が増えそうです。

AWS内に構築した管理用EC2にSSMを利用して接続

管理用に構築したEC2インスタンスにSSMのセッションマネージャで接続し、
EC2にアタッチされたIAMロール(インスタンスプロファイル)を利用する運用です。

アクセスキーは不要です。

CloudShell

AWSマネジメントコンソール右上のボタンをクリックするとすぐ利用開始できます。マネジメントコンソールにログインしているIAMユーザ（ロール）の権限でシェル操作ができます。

アクセスキーは不要です。

待望の新サービス AWS CloudShell がリリースされました！ #reinvent | DevelopersIO

観点1: IAMアクセスキー

今回はベストプラクティスに沿いIAMアクセスキーを使わずに済む方式を優秀として評価しました。繰り返しになりますが、アクセスキーを使う場合には、できるだけIAMユーザには最小限の権限を持たせ、MFAも設定しましょう。

場所	IAMアクセスキー
ローカル端末	△必要
EC2 + SSH	○不要
EC2 + SSM	○不要
CloudShell	○不要

観点2: 操作ログ記録

以下2つのログ記録について比較します。

シェル操作ログ
AWS APIの操作ログ

シェル操作ログ

SSM以外は、各自ターミナルやSSHクライアントの設定をしておく、scriptコマンドを実行する、などの用意が必要になります。

場所	IAMアクセスキー	シェル操作ログ
ローカル端末	△	△ 各自用意
EC2 + SSH	○	△各自用意
EC2 + SSM	○	○ S3, CloudWatchLogsへの自動出力機能あり
CloudShell	○	△ 各自用意

ここは唯一自動でログ集約してくれる機能を有する「SSMを経由した接続」に軍配が上がりそうです。

この機能を詳しく説明した記事はこちらをご覧ください。

AWS Systems Manager Session Managerのシェル操作をログ出力する | DevelopersIO

AWS APIの操作ログ

CLIを経由したAWS APIの操作ログは、いずれのパターンでもCloudTrailから確認することが可能です。
誰がいつ該当のAPIを叩いたのかなどなど確認することが出来ます。

試しにSTSのGetCallerIdentity APIを実行して、CloudTrailの出力を並べてみました。
※ アクセスキー、SSM、CloudShell、いずれも元のIAM認証情報はスイッチロールで取得しています。

差が出る点を囲んでみました。
主に発行元IPアドレスと、誰がAPIを叩いたかの追いやすさが異なりました。

特に気になるのは、「誰がAPIを叩いたか」だと思います。

ローカル端末からの接続は、スイッチロールセッション名を元にCloudTrailをたどっていくことで元のIAMユーザを特定する事ができます。
CloudShellは親切にもスイッチロール前のIAMユーザ名が(セッション名として)表示されました。

一方、SSHでは EC2のインスタンスID以上の情報は拾えませんでした。

SSMもEC2のインスタンスIDが記録されますが、SSMは以下のように過去のセッションの記録から該当時間帯に接続したユーザがわかります。
合わせて前述のシェル実行履歴を保管していれば、そこから特定することもできそうです。

CloudTrail内で完結するローカル端末とCloudShellに軍配が上がりそうです。

場所	IAMアクセスキー	シェル操作ログ	AWS API操作ログ
ローカル端末	△	△	○ IAMユーザまで追跡可能
EC2 + SSH	○	△	△- 別途EC2ログインユーザを特定する仕組みが必要
EC2 + SSM	○	○	△+ セッション履歴、シェル操作ログからユーザ特定
CloudShell	○	△	○ IAMユーザまで追跡可能

観点3: 環境構築・運用

ローカル端末

AWS CLIのインストール、アクセスキー等credentialsファイルの設定が必要です。
難易度は人によって異なりますが、各個人がローカル環境にインストールするソフトウェアを管理する必要のある環境だと手間かもしれません。

EC2 + SSH

AWS CLIのインストールが必要です。（既にインストール済みのAMIイメージも多いです）
SSHは慣れ親しんだ方法ではありますが、OS内のユーザ管理やSSH鍵の管理、EC2インスタンスの運用が発生します。

EC2 + SSM

AWS CLIのインストールが必要です。（既にインストール済みのAMIイメージも多いです）
SSMの設定が必要です。EC2インスタンスの運用が発生します。

CloudShell

特に必要ありません（AWSマネジメントコンソールにログインできればOK）。

ということで、こうなりました。

場所	IAMアクセスキー	シェル操作ログ	AWS API操作ログ	環境構築・運用
ローカル端末	△	△	○	○ (ただし職場ルール等による)
EC2 + SSH	○	△	(△-)	△EC2管理
EC2 + SSM	○	○	(△+)	△ EC2管理
CloudShell	○	△	○	○ 不要